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Please amend the paragraph at page 9, line 1-page 10, line 5 as follows 

When the Agile Manager and its modules are used in conjunction with the Agility 
Management Process, people are better able to work together in a way demonstrated to be 
correlated with high performance: 

Fosters a more adaptive culture (e.g., to relish change and fight inertia): 
linking goals, projects and their attributes and being able to sort the portfolio to 
focus on a particular aspect facilitates adapting to changes when they occur. 
Helps align users behind strategic goals and contributing projects: getting 
users to "see" in simple outline form where the organization wants to go to grow 
and prosper, and what it's going to take to get there, which enables users to 
understand the strategy and to keep their own projects in alignment. 
Helps employees act and be treated like owners: when people can see a model 
of the organization and understand how it works they are better able to make 
decisions about what is important, much as if they owned the organization. 

• Helps make decisions based on benefits and risks to the business: linking 
proposed initiatives to the model of the organization, and to costs, paybacks, and 
priorities makes it easier to understand the benefits and risks that could result. 

• Provides well managed structure that encourages teamwork across 
boundaries: the ability to understand and be informed of changes elsewhere in 
the organization enhances the ability to work across different disciplines and 
locations.. 

• Encourages people to continuously look for ways to improve the business: 

enabling management team members to review a table of contents of their 
business, and to assess gaps between how good they need to be and where they 
are currently, and to set goals for closing these gaps; this ability of individuals or 
teams to step back and to "see" the table of contents and to^ reflect on what 
changes need to be made to be different in the marketplace and to improve 
performance is a key ingredient in creating a culture that continually looks for 
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ways to improve the business. 

Helps people understand better how the pieces of the business work together: 

the model of the business gives viewers an integrated view of how the business 
works and how they relate, which provides a valuable context for understanding 
why something that does not entirely make sense locally could be proper for the 
business as a whole. 

• Keeps users focused on successfully implementing strategic priorities: The 

ability to constantly view and be aware of what is in the approved strategic goals 
and initiatives portfolio keeps members of the organization aligned around 
common strategic priorities 

• Makes the management process more cost effective by having information 
and knowledge available when it is needed: the linking of plans, goals, 
resources, people and projects into a relational database accessible via the Internet 
makes valuable information available almost immediately. 

Please amend the paragraph at page 14, line 30-page 15, line 9 as follows: 

For example, even if a goal "expand business with the most profitable customers" has 
been entered, ideas related to the goal have not been entirely fleshed out, resources have 
not been allocated, plans have not been formulated, and accountability has not been 
assigned. The goal is without projects necessary to bring about the desired results. To 
begin to put these projects together, users can use the gap analysis feature to view each 
domain and sub-domain in terms of how each domain or sub-domain would have to 
change if the goal is to be achieved. As users identify these changes, they create in effect 
a vision of a different company that would achieve the goal (see Fig. 12). In this example, 
two projects or goals to expand business with profitable customers are: to d ee p e r deepen 
relationships with high net worth clients, and to have profitable products for every 
segment. Each of these two projects or goals may also in turn be analyzed in the gap 
analysis process to create other projects or goals that will make them a reality. 

Please amend the paragraph at page 17, line 25-page 18, line 1, as follows: 
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The Agile Company can be added to or made accessible from the Agile Manager and 
provides a survey that employees can take to assess how well the company or 
organization is managed in view of high performance criteria. The Agile Company 
software can be downloaded onto the client's server and a user on the network can 
complete a questionnaire of multiple pages, such as 20 pages, (exemplified in Fig. 34) 
and then the software can tabulate results to show strengths and weaknesses for sample 
analysis. The Agile Company also has templates that can be made available to help 
clients get started with a change program designed to improve specific high performance 
traits (exemplifi e d in Fig. 36). . The goal "expand business with most profitable 
customers' shown in Fig. 36 is set up with such a template. 

Please amend the paragraph at page 20, lines 12-14 as follows: 

• Rank: (not shown) this heid -field is available for formulas developed for each client 

for calculating the ranking of each goal and initiative, including the combined values 

of initiatives contributing to a particular strategic goal. 

Please amend the paragraphs from page 25, line 24 through page 26, line 20 as 
follows: 

Continuing with domain hierarchies 4008, domain hierarchies may contain only domains 
4009. A single domain 4009 is at the head of each domain hierarchy 4008. A domain 
may have other domains (termed subdomains) as its children. The structure of the 
hierarchy is again indicated by arrows 4434012. Any goal in a goal-project hierarchy 
401 1 may belong to a single domain 4009(i), but a goal need not belong to any domain. 
The top goal in goal-project hierarchy 4011(1) belongs to no domain. The goals that 
belong to a domain may belong to different goal-project hierarchies 4011. These 
relationships are shown in FIG. 40 by arrows 4010. Thus, as show there, goals from 
goal-project hierarchy 401 1(1) and 401 l(m) may belong to domain 401(k). 1 009(k). 

Access to domains, goals, and projects is by collaborator groups 4003. A given 
collaborator group 4003 (i) may have access to any combination of domains, goals, and 
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projects in model 400 1 , as shown by arrows 4007 . The kinds of access which a 
collaborator belonging to a particular group has to a particular domain, goal, or project 
depend on the group's group type and on the permissions which the group has for the 
particular domain, goal, or project. The group's group type determines the maximum 
access that the collaborators belonging to the group may have to any domain, goal, or 
project to which group gives access. The permissions for a particular domain, goal, or 
project determine the actual access that the collaborators belonging to the group may 
have to the particular domain, goal, or project. The access granted by the permissions 
can of course be no greater than the access granted by the group type What a collaborator 
sees of model 4001 depends on the collaborator's group membership and on the 
permissions the group has for the model components. For example, group 4003(1) has 
the user type, which gives the collaborators at most read- write access to domain 
4009(2), domain 4009(k), goal 4013(b) and project 4015(a). That access is further 
limited by the permissions for the group; for example, the permissions may give 
collaborators belonging to the group only read access to domain 4009(2), domain 
4009(k), and goal 4013(b), but read-write access to project 4015(a). Consequently, the 
collaborators can see project 4015(a) and domain 4009(2) by themselves and can see both 
goal 4013(b) and domain 4009(k), as well as the relationship between them, but can 
modify only project 4015(a). 

/** Is this corr e ct? Do e s it d e scrib e th e way things w e r e in th e first version? If not, what 
is new and wh e n was th e chang e mad e ? **/ 

Please amend the paragraph at page 27, lines 4-11 as follows: 

An important feature of the models of the system for collaborative work is that 
collaborators with the proper permissions may modify not only the information 4017 
associated with a goal or project but may also modify the form of a goal-project hierarchy 
4011 or a domain hierarchy 4008. For example, a collaborator who has edit access to 
both domain 4009(k) and domain 4009(2) may make domain 4009(k) a child of domain 
4009(2). Similarly, a collaborator who has write privileges for goals 4013 and 4013(b) 
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may move the subtree consisting of goal 4013(b) and project 4015(a) so that goal 
4013(b) is a child of goal 4013. 

/** is this a corr e ct d e scription of th e acc e ss privileg e s r e quired? **/ 

Please amend the paragraph at page 28. line 25 through page 29, line 2 as follows: 

An initiative 4109 is not a member of any domain hierarchy 4010 or goal-project 
hierarchy 4011, but is rather the root of an initiative hierarchy 4111 which may include 
subinitiatives and a single level of goals and/or projects from any of the goal-project 
hierarchies. A goal or project may belong to any number of initiatives. Collaborator- 
groups 4003 are related to initiatives in the same fashion as they are to hierarchies, as 
shown by arrow 4103. Thus, as shown by arrows 4107, a project in hierarchy 401 1(2) and 
a goal and a project in hierarchy 401 1(1) all belong to initiative 4109(1) and the project in 
hierarchy 4011(1) that belongs to initiative 4109(1) also belongs to initiative 4109(o). 
Information may be related to an initiative in the same way that it may be related to any 
hierarchy entity. It should be pointed out here that initiative is used here and in the 
following in a manner which is different from its use in the parent, where it is employed 
as a broad term that covers both goals and projects. 

Please amend the paragraph at page 30, lines 6-30 as follows: 

The dotted lines in FIG. 42 divide the tables shown in diagram 4201 into functional 
groups that correspond to the different kinds of entity that appear in the model of FIG. 41. 
The collaborators 4005(1. .n) are identified by user_inf o table 4247, which contains a 
row representing each of the collaborators. The collaborators are organized into groups 
4003 by the tables in the portion of FIG. 42 with the reference number 4203. The 
hierarchy entities of FIG. 41 and the hierarchies to which they belong, namely domain 
hierarchies 4010, initiative hierarchies 4111, and goal-project hierarchies 4011 are 
defined by the tables in the portion of FIG. 42 with the reference number 4213. The 
remaining tables in FIG. 42 contain different kinds of information 4017. The tables in the 
portion labeled 4231 and 4251 contain alert information which is used to alert 
collaborators to events that occur in the course of the collaborative effort. The tables in 
the portion labeled 4231 alert collaborators to changes in the model which are of interest 
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to the collaborators, while the tables 4255 and 4257 in portion 425 1, finally, permit 
collaborators to provide time-based reminders to themselves. The tables in the portion 
labeled 4241 record on-line discussions among the collaborators. The contributions to 
the discussions are rows in discussion table 4243 and discussion reply table 4245. Each 
row specifies the row in table 4215 for the hierarchy entity the discussion is about and the 
collaborator who is the source of the discussion. The rows are further threaded, that is, 
the rows in the tables contain fields which make it possible to see the manner in which 
the contributions to the discussion relate to each other both temporally and as 
contributions and replies. The tables in the portion labeled 4219 record information such 
as documents which the collaborators make available to each other; those in the portion 
labeled 4224 record correspondence among the collaborators. As is apparent from the 
arrows emanating from the tables that contain information, the items of information may 
be related to collaborators, to hierarchy entities, or to both. For example, a message 
represented by a row in table 4225 is related via table 4227 to the collaborator to whom it 
is addressed, while an item of information represented by a row in table 4221 is related 
via table 4229 to a hierarchy entity and, as indicated by the arrow to table 4247, to a 
collaborator as well. 

Please amend the paragraphs at page 32, line 1 through page 33 line 30 as follows: 

Group type table 4205 has a row for every group type. In the preferred embodiment, 
there are four group types: site administrator, manager, user, and 
viewer. The group type is identified by GROUP ID field 43 03 Key field 4311; the 
type type's name is contained in GROUPType field 4313. , with the typ e 's name b e ing 
giv e n in GROUPJflAME fi e ld 4305. SECURITYJLEVEL field 4315 is a numeric value 
for the type identified by GROUP ID field 1303 Type Key 4311 . In a preferred 
embodiment, the maximum access given to collaborators by the group types is as follows 
for the various group types: 

• Site Administrator: a collaborator belonging to a group that has the Site 
administrator type may modify the model in any fashion. He or she may create 
Groups, Users, Domains, Initiatives, Goals, and Projects, assign group types to 
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groups, and assign permission levels for any group and hierarchy entity. Such a 
collaborator further has access to all information 4017 and may delete Groups, Users, 
Domains, Initiatives, Goals, Projects, and data. 

• Manager: A collaborator belonging to a group that has the Manager type may in 
general modify existing entities in the model to which the group has access. Thus, 
such a collaborator may add subdomains, subinitiatives, subgoals, and subprojects to 
the Domains, Initiatives, Goals, and Projects to which the group has access and may 
assign permissions to the subdomains, subgoals, and subprojects. A collaborator 
belonging to a group that has the Manager type may add users to the group but may 
not create new groups or new users. 

• User: A collaborator belonging to a group that has the User type may read and write 
Domains, Initiatives, Goals, and Projects to which the group has access and add 
subdomains, initiatives, subgoals, and subprojects to those Domains, Initiatives, 
Goals, and Projects. 

• Viewer: A collaborator belonging to a group that has the Viewer type may read 
Domains, Initiatives, Goals, and Projects to which the group has access, but may not 
modify the Domains, Initiatives, Goals, and Projects. 

/** Is this now corr e ct as r e gards curr e nt usag e ? **/ 

In order to access hierarchy entities, a user must be a member of at least one group. A 
user may be a member of any number of groups. Users are related to groups by user- 
group table 4211, which has an entry for each user for each group the user belongs to. 
An initiative, domain, goal, or project may be accessed by one or more groups. 

Hierarchy entities are related to groups by group-objective table 4209, which has a row 
for each group for each hierarchy entity the group has access to. The row includes three 
fields of interest in the present context: GROUP_ID 4317, which is the ED of the row in 
group table 4207 for the group that the row is relating to a hierarchy entity, 
OBJECTIVE_ID 4319, which is the ID of the row in objective table 4215 for the 
hierarchy entity that the row is relating the group to, and PERMISSION 4321, which 
indicates how members of the group specified by GROUP_ID 4317 may access the 
object. The permission specified in PERMISSION 4321 is a subset of the permissions 
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specified for the group in group type table 420& r4205. Access to hierarchy entities is per- 
entity, i.e., access to a hierarchy entity does not give access to its descendants. Access to 
the hierarchy entities also determines what a collaborator sees in the graphical user 
interface. If a collaborator does not belong to a group that has access to a hierarchy 
entity, the entity will not appear in collaborator's view of the model. The kind of access a 
collaborator has also determines the collaborator's view of the model for the purposes of 
various kinds of actions. 

Objective and initiative-objective tables: FIG, 44 

Objective table 4215 and initiative-objective table 4217 together define the hierarchy 
entities and the hierarchies to which they belong. FIG. 44 shows details of objective table 
4215. There is a row in objective table 4215 for each hierarchy entity and the SQL DDL 
of FIG. 44 shows the fields belonging to each row. OB JECTIVE_ID field 4401 contains 
a unique identifier for the row and therefore for the hierarchy entity represented by the 
row. OB JECTIVE_NAME field 4403 contains a unique name for the hierarchy entity. A 
hierarchy entity may be an initiative, domain, goal, or project, and the value of 
OBJECTIVE_TYPE_CODE field 4405 indicates which of these the hierarchy entity 
represented by the row is. OBJECTIVE_DESC field 4407 is text that describes the 
hierarchy entity. OWNER_USER_ID fi e ld and DELEGATEE__USER_ID fields 4409 
identify users associated with the hierarchy entity. The first field identifies the user who 
controls the entity and the second field identifies a user to whom the first user has 
delegated control. Both users must belong to groups having access to the hierarchy 
entity. PARENT_ID field 441 1 contains the objective id of the hierarchy entity's parent in 
the domain hierarchy to which the hierarchy entity belongs. In the cases of top-level 
domains and initiatives, the value is NULL, since these entities have no parents. The 
remaining fields 4413 contain information about the hierarchy entity. Which fields are 
used in a particular hierarchy entity depends on the hierarchy entity's type. As 
disclosed in the parent of the present application, the graphical user interface will sort the 
hierarchy entities according to the values of many of these fields. At 4415 is shown an 
index on table 5125 4 215 which permits quick determination of the identifier of the 
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hierarchy entity's parent in its domain hierarchy from the identifier for the hierarchy 
entity itself. This index makes it easier to move up a hierarchy. 

Please amend the paragraphs at page 35, line 1 through page 36, line 10 as follows: 

As set forth in the parent of the present patent application, a collaborator may set an alert 
which automatically informs the collaborator of a change in a hierarchy entity which is of 
interest to the collaborator when the change occurs. As implemented in the database 
system of FIG. 42, alerts involve four tables: 

• event log table 4223 4 233 is a list of events that can result an alerts. There is a row in 
table 4 223 4233 for each occurrence of each event. The row includes fields which 
specify the hierarchy entity involved in the event, the type of event, and the change 
that caused the event. It should be also pointed out here that event log table 4233- 
4233 also provides a complete history of the changes in a model. 

• event type table 4237 contains a row for each of the event types. The fields of the 
row contain information about the type including a description of the type. 

• user-alert table 4235 specifies for each hierarchy entity for which the collaborator is 
interested in receiving alerts the kinds of events the collaborator is interested in 
receiving alerts for. The table includes rows for all of the hierarchy entities that each 
collaborator is interested in. A given row includes the ID for the collaborator, the ID 
for the hierarchy entity, an alert mask that specifies the kinds of events the 
collaborator is interested in for the hierarchy entity, and a flag indicating whether 
email is to be sent to the collaborator when an event specified in the alert mask 
occurs. 

• alert queue 4239 relates rows in event log table 4 223 4 233 to collaborators. There is 
a row in alert queue 2531 4239 for each collaborator for which there is an event of 
interest to the collaborator in event log 4233. 

Operation of alerts in a preferred embodiment is as follows: using a window like the one 
shown at FIG. 26, the collaborator sets an alert for him or herself. The result is a row in 
user-alert table 4235 for the collaborator and the specified type of event (here, a delegate 
event). As events that may result in alerts occur, the system creates rows in event log 
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table 4 223 4233 for the events. Event log table 4 223 4233 is periodically queried using 
each row in user- alert table 4235 for events that the row indicates are of interest to the 
collaborator. When one is found, an entry in alert queue 4239 is made for the event and 
collaborator. The current alerts for a user may be found by querying alert queue 4239 for 
the collaborator. 

Reminders work in much the same way. User-reminder table 4 235 4253 contains a row 
for each reminder that a collaborator wishes to receive with regard to a particular 
hierarchy entity. The row includes fields which specify when the reminders are to start 
and the period for which the reminders are to be given. The system periodically queries 
user-reminder table 4253 to determine which collaborators require reminders. Rows for 
the reminders are placed in reminder queue 4255, where they are available to the 
collaborator. Unacknowledged reminders will be continually updated with the number of 
days remaining until due date. If any unacknowledged reminders are overdue, they will 
be continually updated with the numbers of days overdue since the due date. Thus a user 
will have at most one reminder for a specified hierarchy entity. 
/** is th e r e anything else that n ee ds to b e said about alerts and r e mind e rs? **/ 

Please amend the paragraphs from page 37, line 14 through page 39, line 6 as 
follows: 

Navigator menu 4607 displays either the domain hierarchies 4010 or the initiative 
hierarchies 4111, depending on which of the tabs 4611 at the top of menu 4607 is 
selected. As shown, it -menu 4607 displays the domain hierarchies in domain explorer 
4613. A component of a hierarchy may be clicked on to see its subcomponents. A button 
4615 permits a collaborator with the proper access privileges to add or delete components 
of the hierarchy. At the bottom of navigator menu 4607 is a key 4617 to the symbols 
which represent the components of the hierarchy. As is apparent from the foregoing, 
what is displayed in and manipulated from navigator menu 4 617 4607 is the contents of 
objective table 4215. 
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When a collaborator has selected a hierarchy entity in navigator menu 4607, detailed 
information about the entity appears. If the collaborator has checked checkbox 4606, the 
detailed information is displayed in a new window; otherwise, it is displayed in work area 
4619. Checking checkbox 4606 further permits viewing details of several hierarchy 
entities simultaneously. As shown at 5501 in FIG. 55, three hierarchy entities, All 
Domains, User Guide, and ABCQ have been selected. Box 1604 4606 was checked 
after All Domains was selected. When User Guide was selected, window 5503 
was added to the display; when ABCQ was selected, window 5505 was added to the 
display. 

Work area 4619 is divided into subareas. An option in view drop down menu in action 
navigation bar 4625 -4627 p ermits the user to see a closed version of work area 4619 
which shows only a list of the subareas. A subarea on the list may be expanded by 
clicking it. When this option is not selected, the subareas fill work area 4619, as shown 
in FIG. 46. To further expand a subarea so that it becomes visible in its entirety, the 
collaborator clicks on it. As with the hierarchy entities, when check box 4606 is checked, 
a selected component of work area 4619 is displayed in a separate window. When box 
4606 is not checked, the selected component expands in work area 4619. Beginning at 
the top of work area 4619, the first subarea 4623 identifies the selected hierarchy entity 
and provides a description of it. The description is from the selected hierarchy entity's 
row in objective table 4215. Subarea 4623 further contains dropdown menus 4621 that 
indicate actions which the collaborator may perform on the selected entity. Included in 
the actions are editing or deleting the entity, printing the information displayed the 
screen, permitting the collaborator to add entities that are; subordinate to the selected 
entity in the hierarchy, permitting the collaborator to relate information to the entity, 
permitting the collaborator to change the entity's parent, and permitting the collaborator 
to determine the manner in which the contents of work area 4619 are displayed. Editing 
the entity edits the information in the entity's row in objective table 5215 4215 : deleting it 
deletes the row from the table. Adding subordinate entities adds rows to table 5215 4215 
and adding information relates the information to the entity's row. What the collaborator 
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can do with the selected hierarchy entity is of course dependent on the collaborator's 
group membership. 

The next subarea, 4625, contains the documents and links which are related to the 
selected hierarchy entity by objective-information table 4229. There is an entry in 
information table 4221 representing each of the documents and links. Selection of a 
document or link results in a local copy of the document or link being displayed by the 
program used to edit or read the link in a separate window. In a presently-preferred 
embodiment, if the collaborator makes changes in the document, the collaborator must 
add the version with the changes to documents and links access 4625. In other 
embodiments, the document may be a shared copy which is accessible to the server in 
which the system runs, and in that case, the collaborators may jointly edit the document. 
Discussions subarea 4629 displays any discussions about the selected hierarchy entity by 
members of the group to which the collaborator belongs. What the collaborator sees and 
does in this area is determined by the tables in area 4241 of FIG. 42. Details subarea 
463 1 contains detailed information about the selected hierarchy entity. The information 
comes from the entity's row in objective table 4215. Also included in this area, as shown 
at 4 625 4632 , is the list of the hierarchy entities that are descendants of the selected 
hierarchy entity; clicking on one of those entities causes the information about the entity 
to appear, in a separate window if box 4606 has been checked. Message center subarea 
4633, finally, is a list of the messages for the collaborator. The messages are of course 
from message table 4225 and are related to the collaborator by user-message table 4227. 
In implementations with alerts and reminders, there is another subarea for alerts and 
reminders relevant to the user. 

Please amend the paragraph at page 39, lines 16-26 as follows: 

FIG. 56 shows the GUI for setting and changing a user profile. GUI 5601 is reached via 
the Administration tag in row 4 606. 4604. At 5603 is seen the list of local 
collaborators and groups; one of these, Bart ok, Bella, has been selected. When this 
is done, the collaborator's profile for the system for performing collaborative tasks 
appears at 5605, the collaborator's profile for the third-party software at 5607, and the list 
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of groups the collaborator is a member of at 5609. The information in all of these areas 
may of course be edited by the system administrator. In area 5607, the administrator fills 
in the collaborator's username and password for the third-party software. The result of 
this action is the creation of a row in 3d-pty- sw table 4259 for the collaborator that has 
fields containing the username and password input at 5607. When the collaborator clicks 
on login button 4639, the third-party software is launched using the username and 
password in the user's row of table 4259. 

Please amend the paragraphs at page 40, line 16 through page 41, line 16 as follows: 

FIG. 47 is an example top-level window 4701 for adding an initiative. Navigator menu 
4607 shows the current initiative hierarchies 4111. In that window, the collaborator has 
selected GenAm initiative 4703 and clicked on Action in action navigation menu 4627, 
and has selected Sub Initiative 4707 in drop-down menu 4705, thereby indicating 
that the new initiative is to be a subinitiative of the GenAm initiative or one of its 
subinitiatives. When the collaborator has made the selection, work area 4619 becomes 
the New Initiative work area shown at 5001 in FIG. 50. At 5002, the collaborator 
can specify the new initiative's name; at 5003, the collaborator can specify the parent 
initiative from GenAm and a list 5005 of the initiatives that are subinitiatives of the 
initiative GenAm selected at 4703. Here, GenAm has been selected. At 5004, the 
collaborator can input stage, status, and risk information about the activity, and at 5006, 
the collaborator can input due data- date information. All of this information goes into 
fields 4413 in the initiative's row in objective table 4215. At 5007 is the portion of work 
area 4619 which permits the collaborator to select the permissions which are to be 
granted with regard to the initiative to the groups the user is a member of and that have 
access to the initiative. 

/** Is this the right explanation for th e list of groups in Pcrmiooiono? **/ 

FIG. 51 shows at 5101 how work area 4619 appears after the parent has been selected at 
5103 and the access rights to the new subinitiative have been selected at 5 105. There are 
two groups, ML I and NLF; the collaborator who is creating the new subinitiative has 
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given group ML I read and write access and has given group NEF only read access. 
Of course, these access rights must be among those permitted by the group types of the 
ML I and NEF groups. Also of interest in window 5101 are Objective field 5107, into 
which the user can input a description of the new initiative, and Key Benefit field 
5109, into which the user can input a description of its key benefit. FIG. 52, finally, 
shows at 5201 how existing goals and projects (termed activities and resources 
in this version of the GUI) are assigned to the new subinitiative. Goals are assigned at 
5203; the list 5205 on the left shows all of the goals currently available to be assigned to 
the new subinitiative. /** What determin e s which activities ar e on this list? **/ To 
assign a goal to the subinitiative, one selects the activity and then clicks on the arrow that 
points to list 5207 of the goals that presently belong to the subinitiative. To remove a 
goal from a subinitiative, one selects the goal to be removed in 5207 and clicks on the 
arrow that points to list 5205. Projects are assigned in the same fashion at 5209; the list 
of available projects is at 521 1 and the list of currently assigned projects is at 5213. 

Please amend the paragraph at page 42, lines 5-11 as follows: 

The graphical user interfaces for adding domains and projects are similar to those for 
adding initiatives and goals. A collaborator may reposition a domain in a domain 
hierarchy 4 010 4008 , a goal-project hierarchy 4011 relative to a domain 4 007 4009 , or a 
goal or project within a goal-project hierarchy by selecting a different parent for the 
domain, a different parent domain for the goal-project hierarchy, or a different parent for 
a goal or project. A collaborator may also add descriptions, stage, status, and risk 
information 5004, scheduling information 5007 5006 , and access information 5007 for 
domains, goals, and projects in the same manner as described above for the initiative. 

Please amend the paragraph at page 42, line 29 through page 43, line 7 as follows: 

FIG. 48 shows how information is added to a domain. The domain has been selected in 
navigator menu 4607 and the work area 4619 that appears for the domain is shown at 
4801. The domain is identified at 4803. The collaborator has selected the Add drop- 
down menu 4802 from action navigation menus 4627, and in that menu, he or she has 
selected information 4805. As a result of the selection, window 4901 shown in FIG. 
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49 appears. The window permits the collaborator to describe the document that is being 
provided as information. At 4903, the collaborator inputs the document's title; at 4905, 
the document's type, in this case, one that is stored locally to the server upon which the 
system for performing collaborative work is written. At 4907, the collaborator inputs a 
description of the document, and at 4909 he or she specifies the file location. Browse 
button 491 1 permits the collaborator to browse for the file's location. When everything is 
properly entered, the collaborator clicks on save button 4913. 

Please replace the Abstract of the Disclosure with the following new Abstract of the 
Disclosure: 
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